GPU 裝在公司機房，inference server 也只開內網 IP。團隊鬆了一口氣，準備在簡報上寫「資料不出公司」。

但文件進模型之前，先被送到外部 embedding API；完整 prompt 又被 trace 平台保留；模型完成判斷後，MCP tool 拿著 service key 去修改正式 CRM。模型確實在本機跑，資料卻早已繞過好幾個團隊沒有盤點的出口。

「模型在哪裡」只能回答 inference 那一步。要談資料駐留，得把整條 workflow 拆開看。

先別把 open weights、open source 與 self-hosted 混在一起

這三個詞常被寫在同一張架構圖上，意思卻不同。

open weights 表示團隊可以取得並執行模型權重，實際可修改、再散布或商用到什麼程度，仍取決於授權。open source AI 涵蓋的範圍更廣，不能只看到權重可下載就直接畫上等號。self-hosted 則是部署選擇，表示某個服務由團隊自己運行，不保證模型本身開放，也不保證周邊服務都在同一個環境。

《The State of Open Source AI v1.1》談到 open model 從採用走進 production 時，落差不只出在模型能力，也出在 operational tooling 與 trust。這個觀察很符合實務經驗：把權重載進 GPU 通常不是最難的一段，難的是後面的權限、記憶、工具、sandbox、監控與稽核。

所以，自架模型不是隱私結論。它只是讓團隊控制了一個 runtime。

資料出口至少要查五個位置

我在看 AI workflow 時，會先畫資料路徑，不急著畫模型架構。模型只是其中一個節點，下面五個位置都可能跨出原本的信任邊界。

1. Input 與 context

Prompt 從哪裡來？Agent 是否會讀 repo、issue、客服 ticket、設計稿或客戶附件？讀取前有沒有做資料分類與遮罩？

「Agent 可以讀整個 workspace」對開發很方便，對稽核卻太模糊。至少要知道它實際讀了哪些檔案、由哪個身分授權，以及內容有沒有被帶進後續請求。

2. Retrieval

模型在內網，不代表 retrieval 也在內網。文件切片可能交給外部 embedding 服務，向量可能存進託管資料庫，查詢結果也可能被 cache。

這一層最常被漏掉，因為架構圖只畫一個「RAG」方塊。真正需要確認的是 embedding 在哪裡算、索引放在哪裡、原文是否保留，以及刪除來源文件後，衍生資料多久才會消失。

3. Model routing

現在的 Agent 不一定永遠呼叫同一個模型。GitHub Copilot CLI 在 2026 年 9 月的更新中，將 Project HydraFusion 的 adaptive model orchestration 放進 experimental 功能。這裡能得到的工程提醒很單純：執行路徑可能依策略改變。

這不代表該功能會把資料送去哪裡，也不能據此推論它的隱私政策。反而應該問自己的系統：router 改選模型時，會不會順便改變 region、provider、retention policy 或可用工具？如果會，資料政策就不能只綁在 Agent 名稱上。

4. Tool call

MCP 或一般 API 讓模型的輸出變成動作。此時風險不只是哪一段文字被傳出去，還包括 credential 可以讀什麼、寫什麼，以及錯誤操作能否復原。

HubSpot 2026 年秋季的開發者更新同時出現 user-level apps、service keys、app actions、AI connectors 與 MCP 等 surface。它不是所有 MCP 系統的通則，卻把問題示範得很清楚：模型外面還有身分、正式資料與 read/write 權限。

一個只允許查詢測試資料的 token，跟能修改正式 CRM 的 service key，不能放在同一種風險分類裡。

5. Observability 與 artifact

Trace 很好用，尤其在查 Agent 為什麼選錯工具時。但如果平台把完整 prompt、retrieval 結果、tool response 與附件路徑都收進去，它本身就是一份高密度資料副本。

除了 trace，還要看輸出檔、暫存目錄、物件儲存、備份與人工交接。團隊常把模型輸出下載到本機後就當成「已離開系統」，實際上 provider log、workflow database 與備份可能還各留一份。

用一筆 data-path record 逼自己講清楚

我會替每個 step 留一筆短紀錄。下面是 team-owned inventory 的範例，不是 Mozilla、GitHub、HubSpot 或 MCP 的官方 schema。

step_id: retrieve-ticket-context
data_class: internal-confidential
runtime: external-embedding-service
network_egress:
  destination: approved-embedding-provider
  region: ap-northeast-1
credential:
  owner: support-ai-service
  scope: embed-only
retention: 7-days
write_target: managed-vector-store/support-index
evidence:
  - provider-request-id
  - retention-policy-version
  - deletion-test-2026-09

欄位不用多，重點是每一格都能找到負責人與證據。

runtime 記錄真正執行的位置，不寫模糊的「AI service」。network_egress 列出目的地與區域。credential 要能看出 owner 和最小 scope。retention 不能只寫「依供應商政策」，應固定到團隊接受的期限與版本。write_target 則讓 reviewer 知道副作用落在哪裡。

最後的 evidence 最容易被省略，也最有用。設定畫面截圖只能證明某個人看過設定；request ID、刪除測試、read-back 結果或固定產物，才比較能證明 workflow 當時真的照預期執行。

Router、tool、trace provider 或 retention policy 一改，相關紀錄就該失效重驗。只在換模型時做一次安全檢查，會漏掉更多日常變更。

Hybrid 沒有原罪，藏起來的 Hybrid 才難管

一條 workflow 同時使用本機與外部服務，不必然比較不安全。問題是團隊口頭上稱它為 local-only，實際路徑卻沒有人說得完整。

比較務實的做法，是把工作依性質拆開：需要語意判斷的步驟交給經核准的模型；固定尺寸、格式轉換或檔名生成留給 deterministic tool；會修改正式資料的操作則另設最小權限、人工 approval 與 read-back。

例如設計師確認 AI 產圖可用後，可以用 Resize Image for Instagram 在瀏覽器本機完成 1080×1080、1080×1350、1080×1920 或 1080×566 的尺寸輸出。該工具的 resize、fit／crop／padding、preview 與 PNG export 都在瀏覽器進行，來源圖片不送到伺服器處理。操作員再把檔名、尺寸與交付路徑記進 evidence。

這只能證明「圖片尺寸轉換」這一步的 data path。上游產圖是否送出資料、下游發布是否呼叫外部 API，仍要各自檢查。局部的本機處理，不能替整條流程背書。

什麼情況下，自架才真的值得

如果團隊需要控制模型版本與 runtime、有明確資料駐留要求，而且願意承擔 serving、patch、monitoring 與 incident response，自架很合理。前提是周邊路徑也納入同一套治理。

反過來說，如果團隊只能控制 inference server，卻答不出 embedding 在哪裡算、router 會切到哪個 provider、MCP 拿了什麼權限、trace 留多久，那張「全本機 AI」架構圖只是把未知藏在模型方塊外面。

先縮小可進入 workflow 的資料範圍，訂出明確的 hybrid policy，通常比急著貼上 local-only 標籤更可靠。

別問是不是本機 AI，問資料每一步去了哪裡

判斷一條 AI workflow 是否可用，不該停在「模型有沒有自架」。拿一筆真實資料走完整條路，逐步回答四件事：它去了哪裡、誰能讀、誰會保留，以及團隊拿什麼證明刪除或寫入已完成。

只要其中一格答不出來，那就是下一個該補的工程工作。GPU 在哪間機房，反而沒那麼重要。

資料來源

• The State of Open Source AI v1.1
• GitHub Copilot weekly releases — September 7
• Fall 2026 Spotlight — HubSpot Developer / Builder Updates